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ABSTRACT 

The widespread adoption of standard packet-based 
data communication protocols and services for 
spaceflight missions provides the foundation for other 
standard space data handling services. These space 
data handling services can be defined as increasingly 
sophisticated processing of data or information 
received from lower-level services, using a layering 
approach made famous in the International 
Organization for Standardization (ISO) Open System 
Interconnection Reference Model (OSI-RM). The 
Space Data System Interconnection Reference Model 
(SDSI-RM) incorporates the conventions of the OSI- 
RM to provide a framework within which a complete 
set of space data handing services can be defined. 

The use of the SDSI-RM is illustrated through its 
application to data handling services and protocols 
that have been defined by, or are under consideration 
by, the Consultative Committee for Space Data 
Systems (CCSDS). 

Key Words: Space communications, CCSDS, 
telemetry, telecommand, ISO/OSI 

1. INTRODUCTION 

Over the past decade, the world community of 
civilian space agencies has fostered the evolutionary 
adoption of standards for operational space data 
communication systems. Early efforts at 
standardization concentrated on the transfer of data 
across the space-ground radio frequency (RF) link. 
These efforts resulted in a packet-based statistical 
multiplexing alternative to time division multiplexing 
(TDM); powerful forward error correction for 
telemetry; and a reliable command delivery protocol. 
These standard mechanisms are documented in the 
CCSDS Recommendations for Packet Telemetry 
(Ref. 1) and Telecommand (Refs. 2 - 4). 

Prompted by the prospect of an international space 
station containing hundreds of instruments and 
platform control functions communicating with a 
world-wide user community on the ground, CCSDS 
extended the scope of standardization. The 
expanded-scope services and protocols, documented 
in the CCSDS Recommendation for Advanced 
Orbiting Systems (AOS) (Ref. 5), comprise (a) an 


expanded suite of space link services and protocols 
(e.g., bitstream, isochronous insert), and (b) end-to- 
end data transfer services (e.g., onboard instrument to 
ground-based telescience workstation). The AOS 
Recommendation introduces the concept of the 
CCSDS Principal Network (CPN), which is the 
concatenation of onboard, space link, and ground 
subnetworks. 

The aforementioned CCSDS Recommendations were 
developed by starting at the space-ground link and 
working out. This "RF link out" approach is in 
contrast to that taken in the development of Open 
System Interconnection (OSI), an initiative of the 
International Organization for Standardization (ISO) 
which was to create a suite of services and protocols 
that would allow application programs on any two 
arbitrary end systems (aka nodes) to communicate. 
The OSI services and protocols have been created on 
the framework of the OSI Reference Model (OSI- 
RM) (Ref. 6). The OSI-RM allocates the functions of 
data communication to the now-famous seven layers: 
physical, data link, network, transport, session, 
presentation, and application. Because the OSI-RM 
addresses the complete range of functions that must 
be performed to allow two applications to 
communicate, the developers of the specific services 
and protocols at each layer were able to identify and 
mitigate overlaps and shortcomings within the suite 
of services/protocols. 

Such a model for the interconnection of application 
processes is not limited to OSI services and protocols. 
In the context of space data systems, such a model 
could be used to: 

- Provide a framework within which all aspects of 
space data interchange can be identified 

- Identify which aspects of space data interchange 
are suitable to standardization 

- Consolidate fundamental concepts for analysis 
of the data and information processing 
requirements of space missions 

- Foster a terminology common to the space data 
and information handling community 

- Provide the overall context that allows the 
standardization effort to proceed in multiple 
"narrower" activities better suited to the time 
and resource limitations of the standardization 
process 
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Highlight data and information handling 
requirements common to space-based and 
ground-based systems, and thus foster the 
application of approaches and technologies 
common to both. 

This paper introduces such a model, called the Space 
Data System Interconnection Reference Model 
(SDSI-RM). The scope of the SDSI-RM 
encompasses all communications between user 
applications exchanging space-related data. 

The SDSI-RM is a synthesis of several recent space 
data system modeling activities: the CCSDS ground 
infrastructure reference model used in the 
development of CCSDS-standard ground 
infrastructure services (Ref. 7); a reference model for 
the European Space Agency (ESA) Space Data 
Network developed by Theis (Ref. 8); and a space 
mission interconnection model being developed for 
cross-support services between the Goddard Space 
Flight Center and the Jet Propulsion Laboratory (Ref. 
9). These recent modeling efforts focus on different 
subsets of the overall space data communication 
problem, and do not address certain communication 
profiles (such as inter-spacecraft communications) 
and classes of service (such as end-to-end protocols 
and services). The goal of the SDSI-RM is to 
abstract the essential features common to these other 
models, and to provide the conceptual framework for 
defining the currently missing profiles and classes. 

Owing to the introductory nature and brevity of this 
paper, the SDSI-RM as presented here glosses over a 
variety of rough edges that surface through detailed 
analysis. The intent here is to present the core 
features of the SDSI-RM. 

2. SDSI-RM CONCEPTS AND TERMINOLOGY 

The SDSI-RM adopts concepts and terminology of 
the OSI-RM, and augments those as necessary. 

At the highest level, the SDSI-RM is partitioned into 
architectural profiles. These profiles correspond to 
major scenarios for the interconnection of space data- 
handling systems. Each architectural profile is 
defined in terms of the telecommunication services 
that interconnect two user applications. 

User applications are part of, or attached to, end 
systems. Through the cooperation of service entities 
on each of the end systems, a telecommunication 
service is provided between the user applications. 

The telecommunication services are provided in a 
layered manner: a service entity in one end system 
exchanges service data and protocol information with 
its peer service entity in the other end system by 
using the service offered by the layer below. The 


service entity at a given layer is simultaneously the 
provider of a service to the layer above, and a user of 
the service provided by the layer below, with each 
successive service layer adding value to the service 
provided by the layer below. This layering approach 
is successively applied from the medium that 
physically connects the end systems up to the user 
applications. 

The case where two end systems are physically 
connected by a single physical medium is a special 
one. In the more general case, one or more 
intermediate systems lie between the end systems. 

An intermediate system is used to interconnect across 
multiple subnetworks, and/or when a service/protocol 
conversion is necessary between end systems. 

The services within each architectural profile are 
grouped into service classes. Service classes are 
groupings of functionally-related services. A service 
class may be decomposed into more-specific, more 
narrowly defined subclasses. At the bottom of the 
subclassing hierarchy are concrete services (e.g., ISO 
Connectionless Transport Service (Refs. 10 & 11) 
using Transport Protocol class 4 (Ref. 12)). In most 
cases such concrete services have not yet been 
specified. For those cases, the SDSI-RM provides a 
place holder for requirements against to-be-specified 
services and protocols. 

The specification of the different service classes 
within an architectural profile is based primarily on 
layer functionality vis-a-vis the OS I seven-layer 
model. However, classification by OSI layer alone 
does not address the different contexts in which those 
services are used. For example, the same transport 
service may be used to connect two end systems 
directly (an end-to-end context), and also be used to 
connect an end system to an intermediate system (a 
subnetwork context). The SDSI-RM classes reflect 
these contexts, and it is possible for the same services 
to appear in several service classes with the same 
architectural profile. 

There are four architectural profiles in the SDSI-RM: 
space-ground, inter-spacecraft, terrestrial, and intra- 
spacecraft. The space-ground architectural profile is 
the focus of most modeling efforts, so it will be 
presented first and in the greatest detail. 

3 SPACE-GROUND ARCHITECTURAL PROFILE 

The space-ground architectural profile deals with 
interactions between space-borne and ground-based 
user applications. The space-borne user applications 
may be sensors, platform control systems, or, in the 
case of human-occupied spacecraft, astronauts or 
cosmonauts. The ground-based user applications that 


92 



communicate with the space-bome applications 
include science data handling systems, telescientists, 
platform control center processes, and ground 
controllers. 

The space-ground architectural profile contains seven 
top-level service classes: 

- CPN Communication services class 

- CPN Transport services class 

- CPN Internet services class 

- Space Link Access services class 

- Space Link services class 

- Terrestrial Telecommunication services class 

- Spacecraft Telecommunication services class 

Figure 1 illustrates the space-ground architectural 
profile, where the service classes are represented as 
boxed groupings of corresponding service elements. 

3.1 CPN Communication Services Class 

The CPN Communication services class provides the 
interconnected user applications with services 
associated with the OSI-RM's session, presentation, 
and application layers. These services are realized 
through the interaction of peer entities directly 
associated with the communicating user applications. 
The CPN Communication services class contains 
three subclasses: the ISO/OSI Communication 
services class, the Space Operations services class, 
and the Space Information Interchange services class. 

The ISO/OSI Communication services class consists 
of a set of specific ISO-standard services and 
protocols at the application, presentation, and session 
layers. This suite is available for flight projects with 
requirements for OSI compliance. The ISO/OSI 
Communication services use the ISO/OSI Transport 
service class of the CPN Transport services class (see 
3.2). 

While the ISO/OSI communication services class 
provides many services of potential use in space 
flight operations, a growing body of evidence shows 
that use of the ISO/OSI protocols across a space- 
ground link may provide unacceptable performance 
in many operational scenarios. The Space Operations 
Communication services class is intended to provide 
a set of information transfer services equivalent to 
those of the ISO/OSI Communication services class, 
but modified for optimal performance in the space 
operations environment. The Space Operations 
Communication services class does not now exist, but 
CCSDS is contemplating a program of work to 
develop such a suite. Candidates for early 
development are a space-optimized file transfer 
service/protocol and commanding service/protocol. 
The Space Operations Communications services use 


the Space Operations Transport service of the CPN 
Transport services class (see 3.2). 

The Space Information Interchange services class 
comprises application- and presentation-layer 
services constructed around the CCSDS Standard 
Formatted Data Unit (SFDU). The SFDU is the 
currency of a standard system for encapsulating 
information in a way that enhances the identifiability, 
locatability, and archivability of that information. 

The Space Information Interchange services support 
the creation, cataloging, packaging, locating 
(finding), browsing, evaluation, and retrieval of 
SFDUs. 

The Space Information Interchange services are 
currently being defined within CCSDS. As currently 
modeled in the SDSI-RM, the Space Information 
Interchange services can use the services of either the 
ISO/OSI or Space Operations Communication 
services class (or both) to connect across the space- 
ground link. 

3.2 CPN Transport Services Class 

The CPN Transport services class transfers data 
across the multiple subnetworks between the space- 
based and ground-based application processes, while 
providing the level of reliability that is required by 
the communicating user applications. The CPN 
Transport services class contains two subclasses, the 
ISO/OSI Transport service (Refs. 10 & 1 1) and die 
Space Operations Transport service. 

The ISO/OSI Transport service is available for flight 
programs requiring OSI compliance. The ISO 
Transport service uses the CPN Internet service (see 
3.4). 

The Space Operations Transport service is a transport 
service (with supporting protocol) tailored to the 
space-ground telecommunication environment The 
Space Operations Transport service and 
corresponding protocol do not now exist, but CCSDS 
will begin a program of work to develop them in the 
near future. The current thinking is that the Space 
Operations Transport service will use the CCSDS 
Path service of the Space Link Access services class 
(see 3.3) to provide an internetwork connection 
between the space-based and ground-based end 
systems. 

3.3 Space Link Access Services Class 

The Space Link Access (SLA) services class allows 
application processes that are remote from the 
termination of the space link to access the Space Link 
Services (see 3.5) that are provided at that link 
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termination. The SLA services provide access to 
Space Link service date in real-time and on a 
delayed-delivery basis. 

The model of SLA services described in this paper 
actually addresses the simple case of providing SLA 
services when all of the Space Link service protocol 
processing is performed at the space link terminal. A 
general model of the SLA services exists which 
incorporates distribution of Space Link service 
protocol processing. The simple-case model 
described here is a subset of that general model. 

Within the space-ground architectural profile, the 
SLA services class contains two subclasses, the 
Ground-based SLA (GSLA) services class and 
Space-based SLA (SSLA) classes. While the SSLA 
and GSLA services classes provide conceptually 
equivalent services, they differ in the specific 
characteristics of those services and the protocols 
used to provide those services. These differences 
arise from differences in the environments: the 
closed, local-area-networked, single-management- 
domain environment of the spacecraft vs. the 
relatively open, distributed, wide-area-networked, 
multiple-management-domain environment of the 
ground systems. 

All but one of the SLA services are always accessed 
directly by the user application, without die use of 
intermediate CPN Communication or Transport 
services. These direcdy-accessed SLA services 
provide several different ways for moving mission- 
unique-format data between the space-based and 
ground-based user applications. The Path service 
(Ref. 5) does not always bypass the intervening 
layers: it provides a space-operations-optimized 
network service through the space link in support of 
Space Operations Transport and Space Operations 
Communication services. (The intervening layers 
may also be bypassed for Path service, so that the 
user applications may operate mission-unique 
communications and transport protocols through the 
Path service.) 

The SLA services are provided by a client-server 
mechanism, with the server entity accessing Space 
Link Services in an intermediate system that 
terminates one end of the space link, and the client 
entity contained within the user application's end 
system. The GSLA server and client entities 
interconnect via Terrestrial Telecommunication 
services (see 3.6), and the SSLA server and client 
entities interconnect via Spacecraft 
Telecommunication services (see 3.7). 

Standard GSLA services are currently under active 
development within CCSDS. The SSLA class is not 
being considered for multi-mission standardization at 


this time. However, the SSLA class provides a 
reference model for individual flight programs to use 
in developing onboard service architectures that 
complement the services that will be encountered on 
the ground. 

3.4 CPN Internet Service Class 

The CPN Internet service class contains one concrete 
service, the CPN Internet service(Ref. 5), which 
provides the ISO Connectionless Network Service 
(Refs. 13 & 14) between the space-based and ground- 
based end systems. CPN Internet service entities 
exist in the two end systems, and in the intermediate 
systems containing the Space Link service entities. 

3.5 Space Link Services Class 

The Space Link services class supports the SLA 
services class by establishing and maintaining a data 
link between the ground infrastructure and the space 
infrastructure onboard a spacecraft. Collectively, the 
services in the Space Link services class: 

- Establish and maintain the RF link between the 
ground and the mission spacecraft. 

- Perform the protocol processing necessary to 
transfer various CCSDS-defined Space Link 
service data units across the space link. 

The Space Link services are the services 
corresponding to the CCSDS Recommendations for 
AOS, Telecommand, and Packet Telemetry. 

3.6 Terrestrial Telecommunication Services Class 

In the context of the space-ground architectural 
profile, the Terrestrial Telecommunication services 
class provides telecommunication connectivity 
between the server and client entities of the GSLA 
services. The Terrestrial Telecommunication 
services class contains two subclasses, the Terrestrial 
Communication services class and the Terrestrial 
Transmission services class. 

The Terrestrial Communication services class 
provides ISO/OSI services and protocols at the 
application, presentation, and session layers. The 
applicability of specific services within this class is 
under study. For example. File Transfer, Access, and 
Management (FTAM) (Ref. 15) is a candidate for use 
in transferring time-delayed files of space data 
between GSLA client and server. 

The Terrestrial Transmission services class provides 
ISO/OSI services and protocols at the transport, 
network, data link, and physical layers. These 
services are used to support the Terrestrial 
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Communication services, and to provide ISO 
Transport and Network services for the transfer of 
real-time space data between GSLA client and server. 

Selection of specific ISO/OSI services and protocols 
to support the GSLA services is a future item of 
work. 

3.7 Spacecraft Telecommunication Services Class 

In the context of the space-ground architectural 
profile, the Spacecraft Telecommunication services 
class provides telecommunication connectivity 
between the server and client entities of the SSLA 
services. The Spacecraft Telecommunication 
services class contains two subclasses, the Spacecraft 
Communication services class and the Spacecraft 
Transmission services class. 

Conceptually, the Spacecraft Telecommunication 
services class provides ISO/OSI services and 
protocols offered in the Terrestrial 
Telecommunications services class, but specific 
services may differ from those selected for the 
ground network because of different requirements to 
support the SSLA services. 

There is currently no work planned within CCSDS to 
standardize Spacecraft Telecommunication services 
or protocols. 

4. INTER-SPACECRAFT ARCHITECTURAL 
PROFILE 

The inter-spacecraft architectural profile deals with 
the communication between application-bearing 
spacecraft. An examples is the communication 
between a free-flyer and Space Station or Shuttle 
during proximity operations. This profile is a simple 
variant of the space-ground profile, with another 
"space half' substituted for the ground half of the 
space-ground profile. 

CCSDS is not currently working on this architectural 
profile. 

5. TERRESTRIAL ARCHITECTURAL PROFILE 

The terrestrial architectural profile deals with the 
communication of space-related data between two 
applications on the ground. This profile essentially 
consists of the Terrestrial Telecommunication 
services class found in the space-ground profile, 
augmented by the Space Information Interchange 
services class. The assumption that the terrestrial 
profile is populated by standard ISO/OSI protocols 
and services is basically a default position in lieu of 
any evidence that these standard services are 


inadequate to the requirements. CCSDS is not 
currently working on this architectural profile. 

6. INTRA-SPACECRAFT ARCHITECTURAL 
PROFILE 

The intra-spacecraft architectural profile deals with 
communication between two applications onboard the 
same spacecraft. This profile essentially consists of 
the Spacecraft Telecommunication services class 
found in the space-ground profile, augmented by the 
Space Information Interchange services class. 

CCSDS is not currently working on this architectural 
profile. 
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